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REMARKS 

This Amendment is responsive to the Office Action dated November 12, 2008. 
Applicant has amended claims 1,16, 32, 39, 46, 55, and 63. Claims 1-91 are pending. 

Examiner Interview 

Applicant notes with appreciation the Examiner Interview of January 13, 2009, between 
the Examiner and Applicant's representatives, namely Kent Sieffert and Jim Shands, wherein 
Applicant's representatives discussed the present invention as it relates to the cited references, 
and proposed claim amendments. 

Claim Rejection Under 35 U.S.C. $ 102 

2. In the Oiticc Action, the Examiner rejected claims I. 16, 32 under 35 U.S.C. 
102(e) as being anticipated by Peterson (U.S. 7421487 Bl). Applicant respectfully traverses the 
rejection to the extent such rejection may be considered applicable to the amended claims. 

Regarding Claim 1 

Peterson fails to disclose each and every feature of amended claim I, as required by 35 

U.S.C. 102(e). and provides no teaching that would have suggested the desirability of 

modification to include such features. Amended claim 1 is recited immediately below: 

A method for distributing traffic flow criteria between network 
devices, the method comprising: 

defining a flow specification data type for a routing 
protocol, wherein the flow specification data type allows a variable 
number of packet flow attributes to be specified for a packet flow 
through a network; 

generating, with a first routing device, a message that 
encodes routing topology information, wherein the routing 
topology information defines at least one route between a first 
network device and a second network device, and traffic flow 
criteria specifying the packet flow in accordance with the flow- 
specification data type; and 

communicating, with the first routing device, the message 
to a second routing device to direct the second routing device to 
control network traffic based on the traffic flow criteria, 

wherein the traffic flow criteria comprises source 
informafion that idenfifies a source network device of the packet 
flow. 
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Claim 1 is directed to a method for distributing traffic flow between network devices that 

comprises generating, with a first routing device, a message that encodes routing topology 

information defining at least one route between a first network device and a second network 

device, and traffic flow criteria in accordance with the flow specification data type. Further, the 

trafflc flow criteria comprises source information that identifies a source network device of the 

packet flow. In this way, Applicant has amended claim 1 to distinguish between routing 

information that specifies a router and traffic flow criteria that specifies a packet flow (i.e., a 

specific flow of packets traversing the network, such as a particular flow from a source to a 

destination for a given protocol). Moreover, amended claim 1 makes clear that the routing 

message includes both : (1) routing topology information defining at least one route, and (2) 

traffic flow criteria specifying the packet flow. 

This is in contrast to Peterson. The Office cites to Peterson, col. 9, lines 44-57, 

reproduced immediately below, to support the assertion that Peterson discloses "defining a flow 

specification data type for a routing protocol, wherein the flow specificafion data type allows a 

variable number of packet flow attributes to be specified," as recited in claim 1 : 

FIG. 4 is a flow diagram illustrafing an exemplary mode of 
operation of router 27 when querying service management system 
14 for QoS informafion. Router 27 initially receives a routing 
protocol packet, such as a BGP packet, that defines a data flow 
within a network (58) . Router 27 may, for example, receive a 
routing protocol packet that defines a new data flow within a VPN, 
such as VPN 22 of FIG. 1. Next, router 27 and, more particularly 
RP process 52A, compares information in the routing 
communicafion with selection criteria (60). RP process 52A may 
apply a route map that compares information in the routing 
communication with the selection criteria. The route map, for 
example, compare a BGP community of a BGP packet, a 
description of an MPLS packet, or IP addresses of an IP packet to 
the route map logic, i.e., the selecfion criteria. (Emphasis added.) 

The routing protocol packet that defines a "data flow" referred to in Peterson is merely referring 
to use of a routing protocol to convey routing topology information of describing a route 
through the network. As seen above, Peterson specifically refers to a Border Gateway Protocol 
(BGP) packet as "a routing protocol packet.. .that defines a data flow within a network." In 
Peterson, BGP allows network devices to communicate routes (i.e., network paths from routers 
to destinations). The BGP messages do not comprise "traffic flow criteria" in accordance with 
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any "flow specification data type," as in claim 1 . In contrast, embodiments of the present 
invention allow BGP to be extended to include these additional "traffic flow criteria" that can be 
used, for example, to specify individual flows of packets from a source device to a destination 
device. In exchanging routing information, the BGP-enabled routers of Peterson do not 
exchange traffic flow criteria that specify individual packet flows. 

Because Peterson fails to teach or suggest all the elements of claim 1, claim 1 is not 
anticipated. Applicants request that the rejection be withdrawn and that claim 1 be allowed. 

Regarding Claims 16. 32. 39. 46. 55. and 63 

Claims 16, 32, 39, 46, 55. and 63 recite elements similar to those recited in claim 1 . For 
reasons similar to those presented above with respect to claim 1, claims 16, 32, 39, 46, 55, and 
63 are also not anticipated by Peterson. Applicants request that the rejection be withdrawn and 
that claims 16, 32, 39, 46, 55, and 63 be allowed. 

5. In the Office Action, the Examiner rejected claims 9, 26, 37, 5 1 , 60, 68 and 71 
under 35 U.S.C. 102(e) as being anticipated by Peterson (U.S. 7421487 Bl). Applicant 
respectfully traverses the rejection. 

As argued above, claims 1, 16, 32, 46, 55, and 63 arc patentable over Peterson. Claims 9, 
26, 37, 51. 60, 68 and 71 incorporate all the subject matter of claims 1,16, 32. 46, 55, and 63, 
respectively, and add additional subject matter, making them patentable as well over Peterson. 
Applicants request that the rejection be withdrawn and that claims 9, 26, 37, 51, 60, 68 and 71 be 
allowed. 

Further, claim 9 requires that defining a flow specification data type comprises redefining 
a preexisting data type of the routing protocol to define the flow specification data type. There is 
no suggestion in Peterson that a preexisting data type for a routing protocol be somehow 
redefined in a manner that allows a specific packet flow to be defined. Contrary to the 
fxaminer' assertion, FIG. 4 does not illustrate a redefined data type for a routing protocol. 
Instead, in FIG. 4 routing information learned via BGP in a conventional manner may trigger a 
query to a management system in order to retrieve QoS information for a route. In no manner is 
a data field of a routing protocol redefined. 
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6. In the Office Action, the Examiner rejected claims 10, 27, 44, 53, 61 , 69, 74, 77, 
80. 83, 86 and 89 under 35 U.S.C. 102(e) as being anticipated by Peterson (U.S. 7421487 Bl). 
Applicant respectfully traverses the rejection. 

Claim 10, for example, requires that defining a flow specification data type comprises 
defining ihe flow specification data type as an application-specifc data type in accordance with 
the routing protocol. There is no suggestion in Peterson that a flow specification data type of a 
routing message is defined as an application-specific data type in accordance with the routing 
protocol . Contrary to the Examiner' assertion, FIG. 4 does not illustrate a defined data type for a 
routing protocol. Instead, in FIG. 4 routing information learned via BGP in a conventional 
manner may trigger a query to a management system in order to retrieve QoS information for a 
route. In no manner is a data field of a routing protocol redefined. 

Claim Reiection Under 35 U.S.C. S 103 

15. In the Office Action, the Examiner rejected claims 2-8, 11-15, 17-25, 28-31, 33- 
36, 38, 40-43, 45, 47-50, 52, 54, 56-59, 62, 64-67, 70,71-73, 75-76, 78-79, 81-82, 84-85,87-88, 
and 90-91 under 35 U.S.C. 103(a) as being unpatentable over Peterson (U.S. 7421487 Bl) in 
view of Bays (U.S. 7139242). Applicant respeclllilly traverses the rejection. 

The applied references foil to disclose or suggest the inventions defined by Applicant's 
claims, and provide no teaching that would have suggested the desirability of modification to 
arrive at the claimed invention. As argued above, Peterson fails to teach or suggest all the 
elements of claims 1, 16, 32, 39, 46, 55, and 63. Each of claims 2-8, 11-15, 17-25, 28-31, 33-36, 
38, 40-43, 45, 47-50, 52, 54, 56-59, 62, 64-67, 70,71-73, 75-76, 78-79, 81-82, 84-85,87-88, and 
90-91 depend either directly or indirectly from one of claims 1,16, 32, 39, 46, 55, and 63, 
making them patentable as well over Peterson. The addition of any disclosure in Bays regarding 
the elements of claims 2-8, 11-15, 17-25, 28-31, 33-36, 38, 40-43, 45, 47-50, 52, 54, 56-59, 62, 
64-67, 70,71-73, 75-76, 78-79, 81-82, 84-85,87-88, and 90-91 does nothing to remedy the 
deficiencies of Peterson. 

Bays discloses techniques that allow a routing control device to perform load sharing of 
traffic flows across network devices. The techniques disclosed in Bays make use of BGP in a 
conventional manner. For example. Bays states at col. 7, line 66 -col. 8, line 4, "Once a control 
peering session has been established, routing control device 20 controls routing in a routing 
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system 30 by injecting routes with better metrics than the ones installed locally. Metrics used 
include local-preference, weight, multi-exit discriminator, and/or others as defined by the BGP 
protocol:' (Emphasis added.) And, at col. 8, lines 42-46, Bays states, "Since routing control 
device 20 is simply a BGP peer using the standard protocol, if the peering session between 
routing control device 20 and the routing system 30 fails all modified routes are flushed from 
the routing system RIB." (Emphasis added.) The techniques disclosed in Bays do not teach or 
suggest BGP messages that comprise "traffic flow criteria" in accordance with any "flow 
specification data type," as in claims 1,16, 32, 39, 46, 55, and 63. In contrast, embodiments of 
the present invention allow BGP to be extended to include these additional "traffic flow criteria" 
that can be used, for example, to specify individual flows of packets from a source device to a 
destination device. In exchanging routing information, the BGP-enabled routers of Bays do not 
exchange traffic flow criteria that specify individual packet flows. 

Furthermore, there is no teaching in either Peterson or Bays that would have suggested 
that it would be advantageous or desirable to modify Peterson to incorporate the elements recited 
in claims 2-8, 11-15, 17-25, 28-31, 33-36, 38, 40-43, 45, 47-50, 52, 54, 56-59, 62, 64-67, 70,71- 
73,75-76,78-79,81-82, 84-85,87-88, and 90-91. As such, claims 2-8, 11-15, 17-25,28-31,33- 
36, 38, 40-43, 45, 47-50, 52, 54, 56-59, 62, 64-67, 70.71-73. 75-76, 78-79, 81-82, 84-85,87-88, 
and 90-91 are non-obvious over the purported combination of Peterson and Bays. Applicants 
request that the rejection be withdrawn and that claims 2-8, 1 1-15, 17-25, 28-31, 33-36, 38, 40- 
43, 45, 47-50, 52, 54, 56-59, 62, 64-67, 70,71-73, 75-76, 78-79, 81-82, 84-85,87-88, and 90-91 
be allowed. 
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CONCLUSION 

All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

\ Name: Mnes L. Shands 

SHU MAKER & SIEFFERT, P. A. Reg. No^ 54,439 

1 625 Radio Drive, Suite 300 
Woodbury. Minnesota 55125 
Telephone: 651.286.8364 
Facsimile: 651.735.1102 
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